Threat Actors Target AWS EC2 Workloads to Steal Credentials
Cloud
We found malicious samples attempting to steal Amazon Elastic Compute Cloud (EC2) Workloads’ access keys and tokens via typosquatting and the abuse of legitimate tools.
Read time: ( words)
Recently, we came across an exploitation attempt leveraging monitoring and visualization tool Weave Scope to enumerate the Amazon Web Services (AWS) instance metadata service (IMDS) from Elastic Compute Cloud (EC2) instances through environment variables and the IMDS endpoint. The abuse of this tool can allow the exfiltration of access keys and tokens to a domain possibly owned by the attacker and uses a dated technique called typosquatting on AWS-owned domain amazonaws.com. This is followed by the use of masscan and zgrab to find Weave Scope user interface (UI) instances and the exfiltration of IP addresses and ports found. We advise users to strengthen, reinforce, and customize their respective cloud security policies, developer-centric tools, and measures to mitigate the impact of compromise from threats and attacks.
Execution flow
We previously reported on the abuse of legitimate tools, specifically abusing Weave Scope, for nefarious purposes. In this attempt on our honeypot, we observed that the attackers gained entry via an exposed Docker REST API server, which is known to be leveraged by threat actors like TeamTNT. In this sample, the attackers created a container and mounted the underlying host’s root directory to the path </host> within the container. Afterward, a script named init.sh was executed when the container was created even without any other command being supplied for execution.
The HOME environment variable is set to /root so that the other processes emanating from this script will consider the /root directory to be the HOME variable. The command history is not logged, and later the environment variable itself is deleted. The PATH variable also contains the path </root/.local/bin>. There are language localization-specific parameters set to enforce the language to be uniform throughout the execution of the script.
Afterward, certain tools that enable the attacker’s script for executing are installed using Alpine Package Keeper or apk to install wget, curl, jq, masscan, libpcap-dev, and docker in the base image for the alpine-based container image. The following two variables are declared:
1. SCOPE_SH, a Base64-encoded string that installs Weave Scope
2. WS_TOKEN, a secret access token that can be used to include hosts in fleets
Script functions
In analyzing the script, we observed and broke down four functions designed for various implementations in the attack: main, wssetup, checkkey, and getrange.
main
The main function calls the other three functions in sequence. Initially, nohup executes the Docker daemon (dockerd) to keep the process running even after exiting the shell. The streams STDOUT and STDERR are piped to /dev/null to show no output on the screen upon execution.
wssetup
This function decodes the content of variable SCOPE_SH using utility base64. wssetup also silently executes the command line scope launch –service-token=$WS_TOKEN to make the host a part of the attacker’s Weave Scope fleet.
Earlier, we observed the exploitation of Docker REST API wherein the scope token is fetched from the attacker’s infrastructure. In this case, however, the token itself is hard-coded in the script.
checkkey
This function checks for the file “/host/root/.aws/credentials”. It is interesting to note that the path /host in the container maps back to the root directory “/” on the host. If the file exists, then it is sent via a curl request to the attacker’s endpoint.
If the function does not find credentials in local file systems and remote file shares (Mitre ID T1552.001 Unsecured Credentials: Credentials In Files), the IMDS endpoints are queried using curl or wget whether they are available or not. The output is processed through a series of grep and sed operations, and the output is accumulated in hidden files “.iam” and “.ec2” (Mitre ID T1564.001 Hide Artifacts: Hidden Files and Directories).
Once the credentials have been gathered, they are combined into one hidden file named “.aws”, separated by two new lines, while the original files are removed. Later, the environment variables of each process are searched for via “AWS” or “EC2”, and appended to the file “.aws” with two new lines added.
Once the file at <$HOME/…aws> is ready with all the credentials collected, the file is exfiltrated to the domain “amazon2aws.com” via curl and then removed.
getrange and rangescan
This function takes in an argument, RANGE, which is later passed on to another function called rangescan. This second function uses zgrab to scan the IP addresses in RANGE for accessible Weave Scope UI on ports 80, 443, and 4040, the default ports used by Weave Scope UI.
Our observations showed there is no value supplied to getrange. Rather it fetches the IP addresses from ipranges.txt, which contains Classless Inter-Domain Routing (CIDRs) that are to be scanned for Weave Scope UI instances. Network enumeration tools like masscan and zgrab are used to find the IP addresses and UI instances. When accessible instances of Weave Scope UI are found, the corresponding IP address and port are exfiltrated using curl to the attacker-controlled server amazon2aws.com.
Domain transferred
Analyzing the attacker-controlled server, we came across a complaint raised by Amazon Technologies, Inc., a research and development subsidiary of Amazon.com, Inc., against the registrant Nice IT Services Group Inc./Customer Domain Admin, the former owner of the malicious typosquat domain. Uniform Domain Name Dispute Resolution Policy (UDRP) is a legal framework for the resolution of domain name disputes among registrants. Reviewing the decision of the administrative panel, we noted that the domain was later transferred to Amazon Technologies, Inc. in June 2022 in the “Findings” section:
Checking with VirusTotal for the IP addresses used to resolve the domain complaint, we observed that the documented history of amazon2aws[.]com and teamtnt[.]red may be related to the threat actor group TeamTNT.
Conclusion
Even though the exposure of Docker REST API has been reduced according to Shodan scan results, it’s important to know that the aforementioned techniques and procedures can be combined with other known or unknown vulnerabilities in the targeted systems. Attackers are consistently working on their arsenal, testing and building different tools, often abusing legitimate tools and platforms. In December 2021, we published an entry about vulnerability CVE-2021-40438 in Apache HTTP Server, which allowed for Server Side Request Forgery (SSRF) when exploited. We have also observed attempts where the AWS IMDS was being queried.
As companies adopt cloud platforms, attackers also build their tools for exploiting these cloud services and infrastructure. As defenders, we need to be aware of what attackers are targeting after gaining entry, as well as which methods are needed to disable, disarm, and contain the threats. We published our research on the possible threat scenarios and mitigation steps since developers use environment variables to store secrets and credentials.
Trend Micro solutions
Trend Micro Cloud One™ – Workload Security equips defenders and analysts with the ability to protect systems against vulnerabilities, exploits, and malware, offering protection from on-premise to cloud workloads. Virtual patching can protect critical systems even before the official patches become available.
Trend Micro™ Vision One™ provides a clear view of the most important events as alerts in a concise manner because the race is about quick responses. Using XDR capabilities with telemetries from your multicloud environments or on-premises workloads, security teams gain a vivid understanding of what to prioritize.
Indicators of Compromise (IOCs)
amazon2aws[.]com Phishing page
ae01fb6c4ab1cf3c12b53ae927e9a4e0b0bc63fe73e4313be223c9f49bdd03fe Trojan.SH.DLOADR.BJ
Tags
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk
